雖然在前面有介紹過可以用 kubectl 的指令來控制 Kubernetes 的資源，但還記得 Immutable 嗎？我們希望我們的 DevOps 架構是 Immutable 的，即使是整個環境遭受嚴重毀損，希望能在 30 分鐘內重建完成。

所以我希望所有的環境設定，都可以被設定檔一鍵還原，你可以把 Kubernetes 想成一堆小物件組合而成的巨大物件，物件裡面有很多屬性，而我們可以用一個 yaml 檔，記錄物件的這些屬性的值，每一次的上版除了 Kubernetes 內建的 history 之後，我們也可以將每次的上版紀錄同步到 git 中。GKE 跟 Git 遠端儲存庫服務要同時陣亡的機率實在太低了，而且就算兩個同時發生，總有同事的本機電腦還有一份 Git 儲存庫吧。

雖然這樣的架構不像異地備援這麼穩，但老實說異地備援這種雙倍成本架構，也不是新創公司能負擔得起的。

deployment.yaml

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80

每一個 Kubernetes 的 yaml 檔，一定會有 apiVersion、kind、metadata 這三個屬性。

• apiVersion：代表你要使用哪個版本的 Kubernetes API 來建立物件
• kind：你要建立什麼類型的物件
• metadata

透過下面的指令，就可以請 Kubernetes 建立一個 Deployment 物件。

kubectl apply -f deployment.yaml

或

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

你可能會想問那 spec 屬性呢！不是每個物件都有的嗎？是的，像下面這個範例，就沒有 spec 屬性。

apiVersion: v1
kind: Secret
metadata:
  name: api-secret
  namespace: default
data:
  tls.crt: ***
  tls.key: ***
type: kubernetes.io/tls

ps: 部分 yaml 內的值有被刻意修改掉，並非完全真實的值。

下一篇開始，我們將介紹幾個常見的物件。

資料來源

• Understanding Kubernetes Objects: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/
• kubernetes API Version: v1.16.0: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/